Support for Value and State

In the kEventControlDraw code above, the same thing (a circle) is drawn no matter what the value of the HIView is. We can just replace the line:

 // having some fun with geometric shapes based on the value of the custom view
 UInt32 i, n = GetControl32BitValue(myData->view);
 switch (n)
    {
    case 0: CGContextAddArc(context, cx, cy, minDim, 0, 2 * pi, true); break;
    case 1: CGContextAddEllipseInRect(context, CGRectInset(bounds, bounds.size.width * 0.4, 0)); break;
    default:
	{
	float deltangle = pi / n, angle = 0, r = minDim / 2;
	CGContextMoveToPoint(context, cx + minDim, cy);
	for (i = 0; i < n; i++)
	   {
	   angle += deltangle;
	   CGContextAddLineToPoint(context, cx + r * cos(angle), cy + r * sin(angle));
	   angle += deltangle;
	   CGContextAddLineToPoint(context, cx + minDim * cos(angle), cy + minDim * sin(angle));
	   }
	CGContextAddLineToPoint(context, cx + minDim, cy);
	}
    }

 // setting our colors according to state: IsControlEnabled, IsControlActive, IsControlHilited
 if (!IsControlEnabled(myData->view))
    {
    CGContextSetRGBFillColor(context, 0.3, 0.3, 0.3, 0.8);
    CGContextSetRGBStrokeColor(context, 0.5, 0.5, 0.5, 0.8);
    }
 else if (!IsControlActive(myData->view))
    {
    CGContextSetRGBFillColor(context, 0.7, 0.7, 0.7, 0.8);
    CGContextSetRGBStrokeColor(context, 0.8, 0.8, 0.8, 0.8);
    }
 else if (!IsControlHilited(myData->view))
    {
    CGContextSetRGBFillColor(context, 1, 0, 0, 0.8);
    CGContextSetRGBStrokeColor(context, 0, 0, 1, 0.8);
    }
 else
    {
    CGContextSetRGBFillColor(context, 0.7, 0, 0, 0.8);
    CGContextSetRGBStrokeColor(context, 0, 0, 0.7, 0.8);
    }

The last thing we have to do is to generate a redraw event whenever the custom HIView’s value or state changes.

Note: This is a radical change from the old style controls if you have been working with them in the past. Most APIs such as SetControlValue, HiliteControl, SetControlMaximum could and would most of the time redraw the control immediately. This meant that if you were calling those 3 APIs in a row for example, the control would be redrawn 3 times in a row. This was generating flicker and was detrimental to the overall performance. In the new world of HIViews, all those APIs just change the private data of the HIView and it is the responsibility of the HIView to issue a redraw event if there is a need for it: for example, changing the maximum value from 100 to 50 when the current value is 25 may need a redrawing (as the slider or scrollbar do) or not (as an indeterminate progress bar). The APIs to call to request a redraw event are HIViewSetNeedsDisplay and its variant forms.

To be alerted of any change of the value or state, we just intercept 2 more Carbon Events: kEventControlValueFieldChanged and kEventControlHiliteChanged. So we change the static EventTypeSpec kFactoryEvents[] declaration in the function GetHICustomViewClass to:

static EventTypeSpec kFactoryEvents[] =
  {
     { kEventClassHIObject, kEventHIObjectConstruct },
     { kEventClassHIObject, kEventHIObjectDestruct },
     { kEventClassControl, kEventControlDraw },
     { kEventClassControl, kEventControlValueFieldChanged },
     { kEventClassControl, kEventControlHiliteChanged }
  };

And we add 2 more cases in our case kEventClassControl switch in the function Internal_HICustomViewHandler:

case kEventControlValueFieldChanged:
case kEventControlHiliteChanged:
	{
	// just asking for a redraw
	HIViewSetNeedsDisplay(myData->view, true);
	break;
	}

That’s it for the support of value and state, it’s all in the kEventControlDraw handler which is really the center piece of your custom HIView. You can test the custom HIView for this step by using the project located in the folder “2_Value_State”, and you will see that now, all the Tester controls from the “SetNeedsDisplay true” push button to the “Active” check box have an immediate effect on the display of the custom HIView.

Tutorial: Writing a custom HIView

B) Implementing support for value and state